…del 3)

#406 ingest accepted CycloneDX-JSON only; the SPDX→CycloneDX converter landed in
#409 but was unwired. This enables SPDX end-to-end:

- sbom_ingest_service.validate_uploaded_sbom: format-dispatch validator. The
  O(n) byte-depth pre-check runs BEFORE any json.loads (incl. detect_format's)
  so a deeply-nested document is a clean 422, never a RecursionError → 500.
  CycloneDX keeps its existing structural gate; SPDX-JSON bounds its packages[]
  array (same cap as components[]); SPDX Tag-Value is bounded by the read cap.
  Content-type / filename allow-list gains SPDX media types + .spdx/.tag (NOT
  the over-broad text/plain). unknown / RDF / XML → 422.

- tasks/ingest_sbom._load_uploaded_sbom: maps the upload to a CycloneDX dict via
  sbom_convert.to_cyclonedx (CycloneDX passes through; SPDX JSON/TV is mapped)
  for persist_sbom_components. The ORIGINAL bytes stay on disk and are handed to
  Trivy, which auto-detects CycloneDX vs SPDX — no lossy round-trip for matching.

- Tests: validate_uploaded_sbom unit cases (real syft SPDX fixtures + adversarial
  RDF/XML/depth/cap, all local-runnable); pipeline test ingests a real SPDX-JSON
  → components persisted + conformance source_format='spdx-json'; API tests assert
  SPDX-JSON and SPDX Tag-Value uploads return 202 (the fake-bomFormat:SPDX 422
  case is unchanged — real SPDX uses spdxVersion).

- docs (EN/KO): the SBOM-upload guide now documents SPDX acceptance, the media
  type / filename allow-list, and SPDX RDF/XML being unsupported.